Appendix A containing a computer program listing is submitted on two identical compact disks. Each compact disk contains a file entitled Appendix A.doc. The file is a Microsoft Word document created on Apr. 8, 2003 and is 255 KB in size. Appendix A is hereby incorporated by reference.
This invention relates to computing architecture, and more particularly to a method and apparatus for running applications solely on a backend server, with the Graphical User Interface of the application running on the client machine in the form of HTML-based web pages.
Computing, in general, can be classified into two categories: Personal Computing and Enterprise Computing. Enterprise Computing, is concerned with the computing activities of an organization and the information infrastructure, including hardware, software and services to support these activities. An organization""s computing activity includes not only that associated with each individual within the organization, but also the collaboration among different members or groups which requires access of different members to different computing resources. Also involved is the collaboration and interaction with other related organizations. In short, Enterprise Computing relates to the information infrastructure to provide each individual entity with access to the right application and data at the right time and the right place.
Traditionally, the architecture of Enterprise Computing is client/server computing, especially Fat Client Computing. Fat Client Computing refers to a computing model in which applications run on both client and server machines, either stored locally or downloaded. Data is also stored locally. A high bandwidth network is used to provide communication between the server and client. In short, Fat Client Computing requires that both the client and server possess enough computing power to run an application and a high bandwidth communication mechanism.
Today, Fat Client Computing is ubiquitous, typically involving server machines such as the Unix/WinNT server, client machines such as PCs running Windows OS, and connectivity being either a high speed LAN or WAN. Though it offers flexibility and lower initial acquisition cost than its predecessors, there are problems associated with Fat Client Computing.
The main concern is the total cost of ownership. Currently the following are four main problems associated with enterprise computing due to its Fat Client Computing architecture:
From a management perspective, traditional enterprise-wide application deployment is often time-consuming, expensive and difficult to maintain. Not only do administrators have to physically distribute applications to every client machine, they also have to deal with version control issues, remote support, multiple system configurations, data replication and protection. When confronted with thousands of users, the cost of application ownership is quickly out of control.
Today""s corporate IT system comprises of a mix of heterogeneous hardware systems and platforms, network connectivity and operating systems. Many applications run on only a certain platform and are installed on only certain computer systems that people from other platforms or other computer systems have problems in accessing. Workers spreading around the world want to access the same set of data and information such as employee information. Companies want to let customers and suppliers access some information traditionally only available within the company, such as order status, but with no idea of what kind of computer system their customers and suppliers are using.
Moreover, most corporate applications today are designed for high speed networks and powerful computer systems. This type of design puts tremendous strain on corporate networks, and the growth of the network bandwidth cannot keep up with demand. Additionally, this type of design yields poor performance on lower bandwidth networks, or is even impossible to run due to bandwidth limitations. Moreover, much of the time, a slow network such as the Internet is the only available connection. Because of this, many users simply refuse to use vital applications and access vital data to get their work done. When this happens, redundant work and significant decreases in productivity may incur.
Additionally, security is a big challenge. In the current enterprise computing architecture, critical applications and data reside both on clients and servers. They are distributed over the whole enterprise. Not only does this increase the risk of unauthorized access to critical information, but also the distributed nature of the applications and data increases the risk of loss or stolen information.
Due to the problems of Fat Client Computing, another computing architecture, called Thin Client Computing, is gaining momentum. Thin Client Computing is a generic term used to describe a group of rapidly emerging technologies that attempt to solve the problems of Fat Client Computing and provide a reduction in total cost though a combination of reduced hardware cost, reduced maintenance and support cost, reduced LAN/WAN bandwidth requirements, reduced down time, improved performance and enhanced security.
Thin Clients bear a resemblance to the dumb terminals in the mainframe age. They rely on the server in order to operate. Most, or, 100%, of the applications run on the server, while the Thin Client acts only as a user interface.
Currently the most widely accepted Thin Client Computing model is based on X-Windows, Microsoft Terminal Server and Citrix technologies. This computing model completely separates an application from its user interface. While the application is 100% running on the server, its user interface is presented on the client machine, which is purely used for user interaction. The user""s input, such as keyboard strokes/mouse movements, originate at the client machine and are transmitted back to the server via the network. The server""s application processes these events and sends its output to the client machine. The communication between client and server is through well-established protocols.
A protocol is a mutually agreed way to present display information and user input information. If the server is a Unix or Linux machine, the protocol will be the X-Windows Protocol. If the server is a Windows machine, the protocol will be the Microsoft Remote Display Protocol, RDP, or Citrix Independent Computing Architecture, ICA. Currently there are three kinds of clients: ie. a native client, a Java client and a web-client.
A native client means that the client program is a native program running on the client machine""s operating system. If the client machine uses a Windows system, the client program has to be a Windows program. A Java client means that the client program is written in Java. By leveraging Java""s xe2x80x9cWrite Once Run Anywherexe2x80x9d capability, a Java client is not limited to a particular kind of Operating System. A web client means that the client program is running inside a web browser, and is either a Java Applet/ActiveX or a browser plugin.
Thin Client Computing in general solves the problems associated with Fat Client Computing by compressing bandwidth and making the client program much smaller. Moreover, Thin Client systems rely on Java so that users do not need to install the program. One simply goes to the web browser and launches the program using Java applets. This implies that applications and data can be centrally managed and maintained.
Nevertheless, Thin Client Computing also has its own set of problems.
First, Thin Client Computing still requires a reasonable network bandwidth, which is higher than the current Internet. Most of the time, the user still needs to install a client program on his/her computer, which is exactly what Thin Client Computing trying to avoid, though the program is much smaller than Fat Client programs. In some cases, the user may not need to install a client program on his/her computer by running a Java Applet or ActiveX based client program, which is downloaded over the network and no installation is required. This is an improvement, but major disadvantages are preventing it from being widely adopted.
Secondly, Java Applet/ActiveX based client programs are not too small, usually close to mega bytes in size. Downloading this size program takes a not small amount of time over corporate networks, and takes over 1 minute or several minutes over the Internet. Moreover, the user has to do this each time an application is to be run. What""s more, the applet needs to be initialized. For instance, the Java Virtual Machine needs to be started, after downloading. This not only adds more traffic to the congested network, but the waiting time to start a program is simply too long.
In summary, the current enterprise computing architecture involving Fat Client Computing has become a major concern with regard to its high total cost of ownership, considering its problems of management, maintenance, access, performance and security. Thin Client Computing, an important step in solving these problems, has performance bottlenecks that limits its wide acceptance.
The other big challenge facing today""s Enterprise Computing is how to adapt to the Internet. This is where web-based computing comes to play in enterprise computing.
As a simple example, today""s companies are trying to use the Internet to communicate more effectively. For instance, UPS lets customers track their packages from its web site, and their IT infrastructure has to adapt to this requirement. UPS has to have programs and computers able to talk to their order tracking system, which may be running on a mainframe. The company has to provide a system which talks to a database system which contains all the information about the customer, which might be running on a Unix server. Moreover the company needs a web server and the ability to publish the information to the web at the user""s request.
UPS is just a very rudimentary example. There are lots of things companies want to do but can not do them because of the limitations associated with currently available technologies. For example, a sales person in Australia may want to check an inventory system which is running on a mainframe system in New York. How can this be accomplished? One way is to rewrite the program on the mainframe so that it can responds to requests coming from the Internet. This will take a long time to develop and may break down the entire system.
The other approach is to leave the mainframe system running as it is, but build an expensive high bandwidth network connecting the Australia office and the New York Office. It is also necessary to install a client program on the sales person""s desktop, which talks to the mainframe. Thus the sales person can use the client program on his desktop to obtain the inventory information from the mainframe in New York. This is the typical Fat Client Computing approach.
Another approach, enabled by the current Thin Client Computing approach, is to have a web server that is connected to the mainframe and have Java Applets stored in the web server. The sales person can simply go to the URL of the web server, download the Java Applet to his desktop and run it from his web browser. The Java Applet talks to the web server, and the web server talks to the mainframe system. As a result, the sales person can get the information he needs. This is the most cost-effective approach. However, performance issues and long waiting times prevent the sales person from being willing to try.
If there were to be a way to run business-critical applications over the web, with good performance, the above problems would not exist.
The subject invention follows the direction of Java Applet/ActiveX based Thin Client Computing approach, which enables running applications over the web, yet avoids the problems associated with this approach, namely the long waiting time to start up a client program, the need to download a large size program, and loading up the already congested network.
In order to avoid the above problems, the subject invention uses JavaScript/DHTML powered web pages as client programs instead of using Java Applet client programs. In so doing, the subject invention takes the backend of Thin Client Computing but replaces its front end, which is the Java Applet client program. JavaScript/DHTML powered web pages are able to deliver a rich featured Graphical User Interface, or GUI, mimicking or copying the original GUI of the application. By using a backend server at which the application is run, coupling the backend server to a web server, and transmitting webpages to a client running a JavaScript/DHTML web browser, the relatively slow Internet can be used, while at the same time providing extremely satisfying performance. In one embodiment it takes only 4 seconds to start a rich full-featured client program, a 10-20 times performance increase compared to Thin Client Computing.
The subject invention not only solves the problem of running applications on the Internet, it also has a profound impact on Enterprise Computing within the corporate environment. Though many companies have high speed networks, these companies can never keep up with network bandwidth requirements. With the subject invention, companies can reduce their bandwidth requirements and deliver the same or better results, while reducing IT infrastructure complexity and cost.
More particularly, in order to solve the above problems with enterprise computing and web-based computing, an architecture is provided for delivering applications over a network, be it Internet or Intranet, in which the application is 100% running on its own server. Each application is presented to client machines via an HTML-based Graphical User Interface or GUI that looks exactly or almost exactly the same as the original GUI of that application.
While it is recognized that HTML has been used for web-based computing, it is limited to very simple applications, and the user interfaces of these programs are dramatically different from the traditional Windows-like GUI that people are used to seeing.
Here, using HTML to construct a Windows-like GUI is part and parcel of the subject invention. It is noted that many have been using HTML for years but were unaware of its power.
To construct a GUI using HTML requires development of a common set of GUI controls such as window, menu, toolbar, icon, scroll, and taskbar. This set of controls, referred to as the xe2x80x9cfoundation classxe2x80x9d, is a major advancement in fully utilizing HTML. It is only possible to construct a windows-like GUI based on this foundation class, which in turn is based on JavaScript and DHTML which are used to develop such a set of GUI components. The difference between HTML without and with this set of controls is similar to the difference between DOS and Windows Operating Systems.
More specifically, traditionally HTML has been used for describing web pages, which features hyperlinks, texts, and images. But very few have imagined that HTML, used together with client-side scripting, can be used to construct a full-featured Windows-like GUI environment, composed of windows, menu, toolbar, task bar, scroll, edit control, tree view, list view, and multiple document interface or MDI. In the subject invention, in one embodiment, a set of common GUI components, with necessary management and communication components, is constructed using Dynamic HTML and JavaScript. This set of components, including window, pop up window, menu/popup menu, tree, table, dialog, scroll, edit control, tool bar, event management, and communication management is constructed beforehand and is used as a foundation for presenting the application""s Graphical User Interface in the exact or similar fashion to its original look and feel.
The Graphical User Interface constructed on top of this foundation is extremely lightweight, on the order of kilobytes. It is based on the widely accepted industry standard, HTML, and is viewable from any popular web browser. It is a feature of the subject invention that the Graphical User Interface mimics the original GUI very well, and delivers performance equal to the original.
Using a computing architecture based on the above-mentioned HTML-based GUI and a Remote Display protocol such as X-Windows, RDP, or ICA, the subject system can deliver almost any application over the web, especially the Internet.
The architecture, in one embodiment includes a client GUI program, which is HTML-based; a web server and an application server which acts as an translation engine; and Window/Unix backend servers on which the applications are running. This architecture enables true web-based computing. As mentioned, people have been using remote display protocols to deliver applications over high speed networks, but can not do this over slow networks. Even when they do, the performance is poor.
The above-mentioned computing architecture, based on the HTML-based GUI, and a Remote Display Protocol, can be used to solve the above-mentioned problems in Enterprise Computing in a way that Thin Client Computing cannot.
Thin Client Computing is an attempt to solve problems associated with Enterprise computing. However it has problems as well and thus it is not as widely used as it should be. Thin Client Computing typically uses one or several remote display protocols and uses either a native client, a Java client or a web client to present the GUI of an application to a client machine. The major problem comes from the client program that the native client needs to install, or from the fact that the Java client and web client requires a long time to download and initialize and adds traffic to the congested network.
In contradistinction, the subject invention replaces the client program with the above-mentioned HTML-based GUI and utilizes the backend of thin computing, which is the remote display protocol and its servers. The HTML-based GUI functions and behaves as well as or even better than these Thin Clients, but requires 10 times less time to download and start. Moreover, it does not add significantly to the traffic on the network.
Using the above mentioned architecture, it is now possible to deliver applications not only in an enterprise environment and the Internet, but also to handheld information appliances such as the Palm Pilot and wireless phones, since the lion""s share of the computing is done on the network instead of at the handheld or portable device.
It will be appreciated that in the subject invention network-based computing is utilized in which the application is never downloaded to the client. Rather, the application is run completely on the backend server, with communication between client and server being through the transmission of requests or responses, which takes the form of web pages. The result is that the slow networks like the Internet can handle the communication, as web pages can be transmitted at 20 Kb/sec, clearly within the capability of a 56 Kb/sec modem.
Since the application is run on a backend server, the computer power at the client is minimal, making possible the use of handheld portable computing devices. Since no programs are downloaded and the client program is minimal, there is no waiting at the client side. Web pages powered by GUI components based on JavaScript and Dynamic HTML offer a pleasing full-featured Graphical User Interface, with the system offering unlimited scalability and high availability. The subject system also enables universal access to applications and data, eliminating performance problems which blocked usage of the Internet or slow local area networks for network-based computing. Use of web pages and associated browsers also offers high security without bogging down performance through the use of the Secure. HyperText Transfer Protocol, HTTPS.
In one embodiment, the entire client program is based on standard HTML technology, mainly JavaScript, Dynamic HTML and Cascading Style Sheet. This client program is extremely lightweight but is able to construct a rich full-featured graphical user interface with the same look and feel as traditional software running on Windows and Unix. An application server and a web server reside between the client and the server. While the web server is responsible for handling HTTP requests, the application application server acts as a translation engine, translating the server program""s display information into web pages using GUI components constructed on top of HTML, ie. Javascript and DHTML, in real time and translating client machine events into the protocol that the backend server understands. A typical computation process is described below:
1. User goes to a client machine""s web browser, enters the URL of the web server;
2. Upon the HTTP request, the web server sends back an HTTP response to the user""s web browser. The response may or may not contain requests asking the user to log on.
3. Upon the successful validation of the user if logon is required, an HTML page is displayed in the client machine that contains information about available applications to that specific user.
4. User clicks on one of the applications. Upon the click, the client program automatically launches a window representing the graphical user interface of that application. At the same time, the user click information is sent back to the web server;
5. Upon receipt of the user click information, the web server may load a predetermined HTML page on the web server and send it back to the web browser, or just pass the information to the application server;
6. Upon receipt of that information, the application server may just do some local processing and send the processing result back to the web server; or the application server will send the information to the appropriate backend server via an appropriate protocol determined beforehand.
7. The backend server responds to the received information, such as opening a file or popping up a message box. The response of the backend server is sent to the application server via a predetermined protocol;
8. Upon receipt of the response, the application server translates the response into HTML, utilizing GUI components constructed beforehand if necessary, and sends it to the web server.
9. The web server sends the translated HTTP response from the application server to the client web browser;
10. Upon receiving the response from the web server, client web browser performs processing as programmed.
11. User generates another request and the above process repeats in a similar fashion.
The communication between the client web browser and the web server is largely based on HTTP or HTTPS. The front end of an application is presented in a client machine""s web browser in a pleasant, familiar Graphical Use Interface, which is constructed by standard HTML technology, mainly using client side script and DHTML. Since it is based on HTML technology, the client program is much more lightweight than traditional Thin Client technologies.
Besides all of the benefits that traditional Thin Client Computing has, the subject system solves the performance bottleneck that troubled traditional Thin Client Computing and offers the following additional benefits:
First, there is a much lower requirement of network bandwidth compared to traditional Thin Client technologies. This makes it possible to deliver applications through not only Intranet, but also the Internet. Performance is still very satisfying even running through a 56 Kb/sec dialup connection. Thus the subject system completely eliminates the bottleneck of web-based computing.
Secondly, there is a much shorter start up time associated with the subject system. Traditional web-based Thin Client Computing requires downloading a program through the web, initiating a Java Virtual Machine if it is an Applet, and starting up the program. This means that the user will not be able to see any feedback until a minute after he sends the request. With the subject system, this performance bottleneck is eliminated as well. Since the client portion is entirely HTML, the user will be able to get feedback within seconds or less.
Thirdly, the Client program is several times smaller than traditional Thin Client programs, thus reducing downloading time by several times.
Fourthly, there is an even lower requirement of client machine. All that is required is that client machine have a web browser that understands standard DHTML and client-side script, such as JavaScript and VBScript.
Fifthly, there is a pleasant Graphical User Interface on the client side by leveraging the power of the web browser, client-side scripting and DHTML. This enables constructing a Graphical User Interface with the exact same look and feel as traditional software, such as Windows applications.
Moreover, there is unlimited scalability and high availability, with the subject system truly enabling universal access to applications and data. While many traditional Thin Client Computing technologies declare this, the reality is that their performance problems stop people from using them over the Internet.
The subject system also features high security without boggling down performance. If necessary, the client program can communicate with the web server through HTTPS, the standard secure protocol that the industry uses today for important transactions. Since popular web browsers have HTTPS built in, using HTTPS for communication will only have a minimal impact on the program""s performance. This is in contradistinction to traditional Thin Clients, in which implementing HTTPS or similar protocols significantly increases the size of the client and slows down the client.
Further, a system is provided for running applications on a desktop or portable computing device having limited computer power, with the web used as the computing environment and with communication between client and server being via the transmission of client-side script and DHTML powered web pages. The result is that it overcomes the bottleneck of current web-based computing not being able to construct a rich full-featured Graphical User Interface with the same kind of look and feel as traditional software, and not being able to deliver traditional software over the web, especially the Internet, with a user-pleasant experience.
This also means that the running of applications is not limited by the computing power available at the device at which the application is run, but rather only by the Internet and the web or application server.
In summary, a computing architecture runs applications on a backend server coupled to an application server, which is in turn coupled to a web server. The web server communicates with a client that is running an HTML-based Graphical User Interface that mimics the original Graphical User Interface of the application. This computing architecture permits the use of relatively slow speed networks such as the Internet or a wireless link between the client and the web server while maintaining the same level of performance as would be expected if the application was running on the client itself, with the communication between the client and the web server involving transmitting web pages to the client and with the client transmitting requests back to the web server in one embodiment via the HTTP protocol. The use of the HTML-based Graphical User Interface provides the user with the same kind of user experience as if he was running the application on the client machine, but without the problems associated with Thin Client Computing such as downloading Java applets or installing a specialized client program for the Graphical User Interface. The subject computing architecture thus permits the use of slow speed networks and computing terminals with limited processing power to run applications that are only available on high speed networks or powerful computers. The use of the subject architecture also permits centralized management of the applications and the data, which in turn permits easy upgrades and maintenance. As a central feature, the subject architecture permits delivery of applications and information over the Internet or other slow speed networks without rewriting the programs and without slowing down performance.